The Universal Mobile Telecommunications System (UMTS) is a third generation mobile communication system (3G), which evolved from the Global System for Mobile Communications (GSM), and is intended to provide improved mobile communication services based on Wideband Code Division Multiple Access (WCDMA) access technology. UMTS Terrestrial Radio Access Network (UTRAN) is essentially a radio access network using wideband code division multiple access for user equipment units (UEs). The Third Generation Partnership Project (3GPP) has undertaken to evolve further the UTRAN and GSM based radio access network technologies. In 3GPP this work regarding the 3G Long Term Evolution (LTE) system is ongoing. Specification is ongoing in 3GPP for the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) which is the next generation Radio Access Network (RAN). Another name for E-UTRAN, used in this document, is the Long Term Evolution (LTE) RAN. The core network which E-UTRAN is connected to is called Evolved Packet Core (EPC), a.k.a. System Architecture Evolution (SAE) network. Both the E-UTRAN and the EPC comprise together the Evolved Packet System (EPS) that is also known as the SAE/LTE network. A base station in this concept is called E-UTRAN NodeB, eNodeB or eNB. The ongoing specification also includes the possibility to have an E-UTRAN base station to provide home or small area coverage for a limited number of users. This base station is, in 3GPP, called Home E-UTRAN NodeB (HeNB), (H(e)NB) and in 3G it is called HNB. This kind of home base stations may in general terms be referred to as a “home Node B” or a “home node” and are in this document further on referred to as a “home node” when described in general terms. Other names used for this type of base station are LTE Home Access Point (LTE HAP) and LTE Femto Access Point (LTE FAP).
In 3G, a HNB Gateway is installed at the mobile core network, providing security, aggregation and core network interfaces for HNBs deployed over the IP access network.
In LTE RAN architecture eNBs serve macrocells and HeNBs serve femtocells. The eNBs and the HeNBs have LTE RAN interfaces S1 to the CN, and LTE RAN architecture comprises X2 interfaces, between eNBs. A HeNB Concentrator Node, which can also be referred to as the HeNB Gateway (HeNB GW), can also be comprised between the HeNB and the CN. In at least some configurations a Security Gateway (SEGW) can be logically placed between the HeNB and the HeNB GW and can serve for terminating IPsec tunnels from the HeNB. The main reasons for having a HeNB GW between the HeNBs and the CN are the following:
1. The assumed number of HeNBs in a network is very high, millions of HeNBs is one estimate.
2. End users can switch on and off the HeNB frequently, causing increased signalling load.
3. HeNBs can be tampered with, e.g. malicious or modified software.
The first issue creates a possible scaling problem in the CN side as each HeNB will have its own S1 interface and it is assumed that Mobility Management Entities (MMEs) are not capable of handling millions of S1 interfaces. Therefore, one purpose of the HeNB GW is to conceal the large number of HeNBs from the CN.
The second issue creates a possible signalling load problem in the CN side and this mostly in the MME due to HeNB S1 interfaces being frequently disconnected and reconnected.
The third issue creates a possible security problem in both the MME and Serving GW as any HeNB that is able to establish an IPsec tunnel to a security gateway of the operator's network can attack these nodes.
The HeNB GW is needed to solve these scaling, signalling load and security issues towards the CN. The HeNB GW will act as an eNB proxy for all the HeNBs that are connected to the HeNB GW. The HeNB GW will, from the CN over the S1 interface, look like one eNB with many cells. From the point of view of an HeNB, the HeNB GW will look like the CN, also S1 interface possibly with some additions or modifications.
The number of HeNBs connected to a HeNB GW is likely to be up to several tens of thousands, ˜100 000, as the number of HeNB GWs in a full network, ˜1 million HeNBs, should not exceed a few tens, ˜10. Thus the number of femtocells “served” by an HeNB GW, an eNB proxy, can be up to a few hundreds of thousands, ˜200 000, assuming a HeNB on average serves a few, ˜2, femtocells.
Some definitions:
Local IP Access (LIPA): Allows an IP-capable user equipment connected via a home node direct access to other IP-capable devices in the local residential/corporate IP network. A IP-capable devices is a device capable of sending and receiving IP packets.
Selected IP Traffic Offload (SIPTO): Offload of selected types of IP traffic (e.g. internet traffic) towards a defined IP network close to the user equipment's point of attachment to the access network. SIPTO is applicable to traffic offload for the macro-cellular access network and for the home node subsystem.
Local Internet Protocol (IP) access and Selective IP Traffic Offload are being standardized for LTE and 3G accesses, allowing the user to get an IP point of presence either at its current base station or at a nearby location. Several solution approaches are currently being discussed. One possible and likely solution approach especially suited for a regular (macro) base station comprises allocating a geographically close GateWay (GW) which corresponds to the Packet Data Network (PDN) GW or Gateway GPRS Support Node (GGSN) in the 3GPP architecture, i.e. the PDN GW or GGSN is local, but for this purpose this local GW may have a reduced feature set, i.e. some more complex function of the PDN GW or GGSN may be omitted such as e.g. on-line charging or Quality of Sevice (QoS) support. E.g. in the case of a home node, a likely solution is to allocate a PDN GW or GGSN, with limited functionality in the home node.
For this to work, functionality is required to enable the selection of that local GW. The GW selection is performed by Serving GPRS Support Node (SGSN) for 3G, and by Mobility Management Entity (MME) for LTE. Even though the current GW selection scheme to a large extent can be re-used, the following issues need to be addressed.                For the case when a UE accesses to internet via 3G access and a close GW, when EPC is not deployed, it is required to be able to select a geographically, i.e., network topology-wise, close GW. The problem is that currently for non-EPC networks there is no way to take location of the UE into account when performing GW selection, other than making the selection SGSN dependant.        When there is a home node GW between the SGSN/MME and the home node, the SGSN/MME needs to be made aware of the IP address of the home node since the SGSN/MME requires to set up a PDP context/PDN connection to the home node and for that procedure the IP address of the home node is needed so that the SGSN/MME knows where to send the setup message to. Otherwise the SGSN/MME has no way to know that address, as it is only aware of the home node GW's address. The MME is the key control-node for the LTE access-network and the SGSN is the key control-node for 3G access network. The MME and SGSN will from now on be referred to in a common term as the “access control node”.        The home node may often be switched on/off and it can get a new IP address each time it is switched on again. The IP address of the home node may also change while in operation, depending on the internet service provider's policies.        
According to one solution, the RAN node (HNB or RNC) suggests an IP address to the GGSN in a new parameter in Iu when a new PDP context is set up. The Iu interface is the interface which links the RNC with either a 3G Mobile Switching Centre (3G MSC) or a 3G SGSN. Regarding this solution to send the GW address during connection establishment to the SGSN (or MME for LTE), the following disadvantages are seen:
A future feature of home nodes is “remote access”, which means that a UE is able to access a local network connected to a home node, which the UE is allowed to access via the 3GPP operator's network. This solution cannot easily be extended for the remote access use case, as it relies on a RAN node sending an address which can only be a local address not a remote address.
In the case of LTE, the IP address of the home node would need to be attached a Non Access Stratum (NAS) message. A NAS message is the control messages that are exchanged between the UE and the core network which are not radio-related messages. However, the NAS messages are encrypted and hence there is no way for the RAN node (eNodeB) to know which NAS message is being sent. This has the consequence that the IP address of the home node GW would be sent for all NAS messages, which means that the address would be sent unnecessarily in a lot of cases. This consumes unnecessary bandwidth and processing.
This approach deviates from the current GW selection procedure which relies on DNS. Hence, this introduces additional implementation burden into the MME/SGSN. The solution requires the RAN node to be configured with the home node GW's address. In some cases, such as a GGSN located near the RNC site, this would pose additional configuration burden on the RNC. This would also mean that a legacy RNC node would not be able to support this feature.